home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9045 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: FreeNet.Carleton.CA!an171
  2. From: an171@FreeNet.Carleton.CA (Anthony Hill)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: 24 Mar 1996 18:19:10 GMT
  6. Organization: The National Capital FreeNet
  7. Sender: an171@freenet2.carleton.ca (Anthony Hill)
  8. Message-ID: <4j43mu$m9t@freenet-news.carleton.ca>
  9. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net>
  10. Reply-To: an171@FreeNet.Carleton.CA (Anthony Hill)
  11. NNTP-Posting-Host: freenet2.carleton.ca
  12.  
  13.  
  14. doug haire (dhaire@gate.net) writes:
  15. > RobertN141 (robertn141@aol.com) wrote:
  16. > : I find this information very interesting. My company manufactures the 
  17. > : AMQUEST HyperModem V.34.  This product will support up to 230,000 BPS
  18. > : throughput and has a enhanced microcontroller architecture to better
  19. > : compress
  20. > : and decompress data.  The fundamental problem with many modems is that
  21. > : they are all rated 28.8 V.34 115,200 max.  However, they lack the
  22. > : horsepower
  23. > : to handle above 88,000 bps throughput. Since in the past many people were
  24. > 
  25. > More hype.
  26. > 
  27. > Listen, first of all, I'd say V.34 modems (and even V.32bis modems) are 
  28. > fully capable of handling a throughput speed above 88k. In fact, I know 
  29.  
  30.     Try running bi-dirrection transfer with both DTEs set to 115.2kbps
  31. and apair of modems using the Rockwell controller.  You'll find that they
  32. do tend to have problems keeping up.
  33.  
  34. > this is true. Second, I'd like to point out that comm overruns are a 
  35. > fault that lies with the operating system software of the CPU. I recently 
  36. > tested this on a comparison with a large file and two different platforms 
  37. > (MS-DOS and Linux) on the same CPU. The sender was a  486dx4/100 CPU running 
  38. > MS-DOS and using a USR Courier V.34 v.everything. The receiver was a 
  39. > 486sx33 with another Courier (same model) running linux and MS-DOS 
  40. > (separate partitions, dual boot). Modems were connected via an 8 ft 
  41. > telephone cable and synched at 33,600 bps with V.42 LAPM and V.42bis 
  42. > compression.
  43. > 
  44. > The linux platform received the file with no errors, no comm overruns, no 
  45. > garbled subpackets, no problems.
  46. > 
  47. > The MS-DOS platform received constant errors such as comm overruns and 
  48. > garbled subpackets.
  49.  
  50.     It isn't so much a case of what operating system you're using, but
  51. what sort of software is talking to you're com port.  Dos doesn't come
  52. with any useful com drivers, so everyone writes their own, to varying
  53. degrees of success.  A really well writing DOS com driver can run at up to
  54. 115.2kbps with a 16450 UART without getting any errors.  Of course, well
  55. writing DOS com software can be kinda rare.  Linux, on the other hand,
  56. does use a com driver (like just about every other OS out there).  Again
  57. though, overruns may occure with one com driver and not the other.
  58.  
  59. > When the common computer software platform is capable of handling 115200 
  60. > properly perhaps we can then consider the 230k UART speed.
  61.  
  62.     Software IS capable of 115.2 speeds now.  In fact, with the right
  63. hardware it's capable of MUCH higher DTE speeds then that (eg Hayes ESP
  64. cards will run at up to 900kbps or so without overruns).  The problem is
  65. that 16550 UARTs can't really go faster then 115.2kbps.  Both 16650s and
  66. 16750s can, and both of those chips have on board flow control, which will
  67. completely eliminate com overruns.
  68.  
  69. Anthony
  70.  
  71. --
  72. Anthony Hill | an171@FreeNet.Carleton.CA
  73.